Subject: Should the C/R bit in SSAP be preserved by DLSw ?

From: Nagi Swaminathan <[email-masked]>
Date: Thu, 10 Feb 94 11:14:38 EST

Steve,

Thank you for your reply. I have a few more questions which I have included  
at the end.

Regards..

Nagi.

>>Reference: Note from Nagi Swaminathan on Wed, 19 Jan 94 15:34:20 EST

>>Nagi Swaminathan writes:
>I have a simple question on the format of SSAP in  XIDFRAME exchanged on the
>network.
>
>Should C/R response bit in the XID frames received from the ring be preserved
>or not when sent as XIDFRAME by DLSw ?
>
> Which one of the following flows is correct ?  What does 6611 do ?
>
> The scenario uses the connection set-up sequence between a PUT2 node and
> a PUT4 node as the example. The PUT2 node initiates the connection by
> by sending a NULL XID command.
>
>1. C/R bit in the SSAP is preserved across the network.
>   ---------------------------------------------------
>
>PUT2             DLSW1                        DLSw2                     PUT4
>
>NULL XID_cmd(SSAP=0x04, DSAP=0x04)
>-------------->
>                 NULL XIDFRAME(SSAP=0x04,DSAP=0x04)
>                 ----------------------------->
>                                              NULL XID_cmd(SSAP=0x04,DSAP=0x04)
>                                               ------------------------->
>
>                                              NULL XID_cmd(SSAP=0x04,DSAP=0x04)
>                                              <-------------------------
>                 XIDFRAME(SSAP=0x04,DSAP=0x04)
>                 <-----------------------------
>
> NULL XID_cmd(SSAP=0x04, DSAP=0x04)
><------------------
> XID_rsp(SSAP=0x05, DSAP=0x04)
> ------------------->
>                  XIDFRAME(SSAP=0x05,DSAP=0x04)
>                  ----------------------------->
>                                                XID_rsp(SSAP=0x05,DSAP=0x04)
>                                                --------------------------->
>
>2. C/R bit is not preserved across the network.
>   -------------------------------------------
>
>NULL XID_cmd(SSAP=0x04, DSAP=0x04)
>-------------->
>                 XIDFRAME(SSAP=0x04,DSAP=0x04)
>                 ----------------------------->
>                                              NULL XID_cmd(SSAP=0x04,DSAP=0x04)
>                                              ------------------------->
>
>                                              NULL XID_cmd(SSAP=0x04,DSAP=0x04)
>                                              <-------------------------
>                 XIDFRAME(SSAP=0x04,DSAP=0x04)
>                 <-----------------------------
>
> NULL XID_cmd(SSAP=0x04, DSAP=0x04) (Note 1)
><------------------
> XID_rsp(SSAP=0x05, DSAP=0x04)
> ------------------->
>                  XIDFRAME(SSAP=0x04,DSAP=0x04)
>                  ----------------------------->
>                                                XID_rsp(SSAP=0x05,DSAP=0x04)
>                                                --------------------------->
>
> Note 1:
> ------
> If case 2 is correct, how can the DLSw1 decide whether to put the XID
> through as a command or a response (see Alan Bartky's message of 7/19/93
> and Steve Klein's message of 8/12/93)?
>

Nagi, the command/response bit in the source SAP is NOT preserved over
>>the network.  The C/R bit is only significant for the local LLC instance
>>on each side of the circuit.  It is only used to acknowledge the receipt
>>of the previous XID LPDU sent by a station and does not change the
>>meaning of the XID for higher layers.  The DLSw LLC in the 6611 uses
>>the following FSM for determining whether or not to set the C/R bit as
>>well as forwarding XIDFRAME SSP messages across the network.  I will add
>>it to the FSMs we are creating for the DLSw standard so that all of
>>the DLSw LLCs are in sync with respect to handling XIDs.
>>
>>Steve
>>
>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>
>>DLSw XID FSM:
>>
>>  XID states
>>    reset - Reset: No incoming or outgoing XID responses are pending.
>>            This is the initial state
>>    IXp   - Incoming XID Response Pending: An XID command LPDU has been
>>            sent and the link station is awaiting an XID response LPDU.
>>    OXp   - Outgoing XID Response Pending: An XID command LPDU has been
>>            received and the next XID sent by the link station should be
>>            sent as a response.
>>    IOXp  - Incoming and Outgoing XID Responses Pending: The link station
>>            has sent and then received and XID command LPDU.
>>
>>  XID events
>>    DLC_XIDr - XID request (from DLSw)
>>    XID cmd  - XID command LPDU
>>    XID rsp  - XID response LPDU
>>
>>  XID actions
>>    DLC_XIDi - XID indication (to DLSw)
>>    XID cmd  - XID command LPDU
>>    XID rsp  - XID response LPDU
>>
>>
>>           +---------------------------------------------------------------+
>>           |                             states                            |
>>+----------+---------------+---------------+---------------+---------------+
>>|  Events  |     reset     |      IXp      |      OXp      |      IOXp     |
>>+----------+---------------+---------------+---------------+---------------+
>>| Receive  | send XID cmd  | drop DLC_XIDr | send XID rsp  | send XID rsp  |
>>| DLC_XIDr | state = IXp   |               | state = reset | state = IXp   |
>>+----------+---------------+---------------+---------------+---------------+
>>| Receive  | send DLC_XIDi | send DLC_XIDi | drop XID cmd  | drop XID cmd  |
>>| XID cmd  | state = OXp   | state = IOXp  |               |               |
>>+----------+---------------+---------------+---------------+---------------+
>>| Receive  | drop XID rsp  | send DLC_XIDi | drop XID rsp  | send DLC_XIDi |
>>| XID rsp  |               | state = reset |               | state = OXp   |
>>+----------+---------------+---------------+---------------+---------------+
>>

Refer to the following scenario. I have included the new states entered borrowing
the notations from your state machine at all receive points.

2. C/R bit is not preserved across the network.
   -------------------------------------------
            DLSw1                               DLSw2

  reset->OXp                                             
  ----------
NULL XID_cmd(SSAP=0x04, DSAP=0x04)
-------------->
                 XIDFRAME(SSAP=0x04,DSAP=0x04)
                 ----------------------------->
                                                  reset->IXp
                                                  ----------
                                              NULL XID_cmd(SSAP=0x04,DSAP=0x04)
                                              ------------------------->
                                                
                                                  IXp->IOXp
                                                  ---------
                                              NULL XID_cmd(SSAP=0x04,DSAP=0x04)
                                              <-------------------------
                 XIDFRAME(SSAP=0x04,DSAP=0x04)
                 <-----------------------------

     OXp->reset
     ----------   (question 1 *1)
                  (question 2 *2)
 NULL XID_rsp(SSAP=0x04, DSAP=0x04)
<------------------

 XID_rsp(SSAP=0x05, DSAP=0x04)
 ------------------->
                  XIDFRAME(SSAP=0x04,DSAP=0x04)
                  -----------------------------.
                                                XID_rsp(SSAP=0x05,DSAP=0x04)
                                                --------------------------->

*1 Question 1:
 -----------
 Alan Bartky had sent some flows where PUT2 node initiates the session 
 set-up to a host. In that the XID_cmd sent by the host  was forwarded as  
 XID_cmd all the way to the PUT2 node. And PUT2 node responded to XID_cmd.
 Following is taken from the mail he sent out on 19 July, 93. This differs from
 the way Finite state machine would behave, that is sending a XID response to the
 PUT2 node. Which is correct ?
 
 *2 Question 2:
 -----------
  When DLSw2 receives the NULL XID_cmd it will drop the subsequent XID_cmds.
  The DLSw1 supposed to retry this XID_cmd. But, if this is sent as XID_rsp 
  the DLSw1 will not invoke this retransmit mechanism. If the XID_rsp gets
  lost in the LAN what happens then ?

  (Note: In QLLC protocol, the protocol used to transport Link Control
         protocol over X.25, the req/rsp information was preserved across
         the network.)  

 Question 3:
 ----------
 When a DLSw goes into  XID dropping mode, shouldn,t there be a mechanism for it 
 to eventually come out of it?. I think after staying in dropping mode for certain
 time period it should enter reset state. This will keep the XID exchange alive
 if the LAN is congested at the same time preventing all the XIDs entering the
 network.
 Alternatively, the  the circuit can be taken down if the XID response is not 
 received and LLC times out. In this subsequent XID received will result in
 the circuit being set-up again. This should be clarified. 

********************************************************************

From Alan Brtky's mail sent on 19 July, 93.

Case 1: SNA/LLC to SNA/LLC (Example Typical PU 2.0 connect sequence)

Station 1                       Network         Station 2        

TEST CMD (D=4,S=0)              Ignore
--------------------->
(Note 1)

TEST CMD (D=4,S=0)             ????????          TEST CMD (D=4,S=0)
--------------------->   -------------------->  ---------------------->
(Note 2)

TEST RSP (D=0,S=4)              ????????         TEST RSP (D=0,S=4)
<---------------------   <--------------------  <----------------------
                                                 (Note 3)

Null XID CMD (D=4,S=4)           ????????        Null XID CMD (D=4,S=4)
--------------------->   -------------------->  ---------------------->
(Note 4)

Null XID CMD (D=4,S=4)          ????????         Null XID CMD (D=4,S=4)
<---------------------   <--------------------  <----------------------

P2.0 XID RSP (D=4,S=4)           ????????        P2.0 XID RSP (D=4,S=4)
--------------------->   -------------------->  ---------------------->
(Note 5)

SABME CMD (D=4,S=4)             ????????         SABME CMD (D=4,S=4)
<---------------------   <--------------------  <----------------------
                                                (Note 6)

UA RSP (D=4,S=4)              ????????           UA RSP (D=4,S=4)
--------------------->   -------------------->  ---------------------->

Note 1: This is a "local" test message (no routing information) and
would only apply to token ring networks.  For ethernet networks, only
"local" test messages would be used, so this would have to cause the sequence
to start.

Note 2: This is the Broadcast test frame using either single route or
or all routes broadcast.  Remember that the SNA station may be downstream
past several bridges and the DLSw switch may receive more than one TEST
command for the same session (you have to key off the MAC SAP address).

Note 3: This is a either a non broadcast response (if all routes was used
in the command) or an all routes broadcast respones (if single route
broadcast was used in the response).  Remember that again several TEST
responses may be received, due to multiple paths due to other bridges and/or
routers.

Note 4: This is a source routed non-broadcast "Null" XID, in this case the
source SAP does equal the destination SAP.

Note 5: This is the PU2.0 XID with the ID NUM and ID BLK (8 digit) PU
2.0 used by the front end's Switched Major Node Table (or by other gateway
device to identify the PU).

Note 6: This is the SABME command to establish the LLC type 2 connection.
There has been some discussion on whether or not the UA should be
sent immediately (with a corresponding RNR frame), or is held off until
the circuit is established (thus no RNR frame needed, this of course
would assume that the XID and TEST frames would be sent without
first establishing a circuit).

**************************************************************************